home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / tsql / doc / tsql.mail / 000071_jcliffor@is-4.stern.nyu.edu _Tue Apr 6 13:42:10 1993.msg < prev    next >
Internet Message Format  |  1996-01-31  |  4KB
  1. Received: from IS-4.STERN.NYU.EDU by optima.cs.arizona.edu (5.65c/15) via SMTP
  2.     id AA28262; Tue, 6 Apr 1993 10:34:44 MST
  3. Received: by is-4.stern.nyu.edu (4.1/1.34)
  4.     id AA11358; Tue, 6 Apr 93 13:42:13 EDT
  5. Date: Tue, 6 Apr 93 13:42:10 EDT
  6. From: Jim Clifford <jcliffor@is-4.stern.nyu.edu>
  7. To: tsql@cs.arizona.edu
  8. Subject: Additional Comments on Benchmark Proposal
  9. Message-Id: <CMM.0.90.2.734118130.jcliffor@is-4.stern.nyu.edu>
  10.  
  11. Greetings, fellow temporal database researchers:
  12.  
  13. I have looked over the current version of the Benchmark schema and
  14. database and would like to register the following additional points in
  15. this e-mail forum:
  16.  
  17. (1) I agree with those who would like to add the Budget attribute,
  18. so that the database will have multiple relation schemes that include a
  19. single-valued, time-varying numeric 
  20. attribute.
  21.  
  22. (2) I was already somewhat confused by the relation currently constituted as
  23.        MGR (Dept Manager)
  24.  
  25. I am even more confused by especially if it is changed to the following:
  26.        MGR (Dept Manager Budget)
  27.  
  28. The discussion in the first paragraph on "Section 2.2 The Schema"
  29. about the E-R model leads one to believe that this relation is intended
  30. to represent a "relationship", but I believe that the natural question
  31. (between which entities?)  leads to the natural answer (Departments and
  32. Managers). However, the proposed schema has no relations that directly
  33. model either of these 2 entities.  What I think this means is the
  34. following two things:
  35.  
  36. (a) this relation should be re-named DEPT. Especially in light of the
  37. added attribute Budget, this seems to be the only appropriate
  38. interpretation. Note that this re-naming is still in conformity with
  39. the stated mutual FD between Dept and Manager.
  40.  
  41. (b) in keeping with the naming conventions seemingly adopted, (namely,
  42. to NOT use the same name for an attribute as for a relation), this
  43. would lead to the following relation scheme instead of the Mgr relation in
  44. the proposal:
  45.  
  46.        DEPT (Department Manager Budget)
  47.  
  48. (3) In the interest of completeness, the discussion about the "keys"
  49. of the relation schemes should be expanded.  Currently, the only
  50. statement about keys is that "Name is the primary key of Emp".  We
  51. should also state the keys of the other 2 relations:
  52.  
  53.   Name is the primary key of Skills
  54.  
  55.   Department is the primary key of DEPT  (if 2a is agreed upon)
  56.  
  57. I will return to the issue of "key" in my last comment.
  58.  
  59. (4) Finally, I have a quarrel with the Proposed Benchmark Data in Section 3.
  60.  
  61. I believe that the following criterion should be used in
  62. populating the agreed-upon schema with data:
  63.  
  64.    the database instance should accord with ALL AND ONLY those 
  65.    constraints which are explicitly stated.
  66.  
  67. The proposed database instance violates the AND ONLY part of this criterion in
  68. at least the following way (and possibly others):
  69.  
  70. there is an implicit assumption about the meaning of being a "key"
  71. that I believe is (i) stronger than necessary, and (ii) at the very
  72. least should at least be made explicit.
  73.  
  74. The only explicit assumption stated about, e.g., the "key" attribute Name in 
  75. relation EMP is  that it obeys the "snapshot function dependency"
  76.    Name --> Salary, Dept, Gender, D-birth 
  77. This means that for all snapshots, no 2 tuples can have the same Name. 
  78. I assume, therefore, that this is the intended meaning of the use of the term "key".
  79.  
  80. However, the proposed database also assumes that the "key" attribute
  81. Name is time-invariant. This is a stronger condition than the notion
  82. of "key" as a "snapshot function dependency," and biases the proposed
  83. benchmark in favor of the tuple-stamped models.
  84.  
  85. I welcome comments on these remarks.
  86.  
  87. --jim--
  88.  
  89.  
  90.  
  91.  
  92.  
  93. ************************************************************************
  94. Jim Clifford                                     jclifford@stern.nyu.edu
  95. Associate Professor                              TEL: (212) 998-0803
  96. Department of Information Systems                FAX: (212) 995-4228
  97. Leonard N. Stern School of Business
  98. New York University
  99. Management Education Center
  100. 44 West 4th Street, Suite 9-74
  101. New York, NY 10012-1126
  102. ************************************************************************